Internet Tools (InfoMagic)/Internet Tools.iso/dos_win/winsock/hacklist/94-04.Z/94-04/[e-mail]_Wed Apr 6 05:37:08 1994.msg

Internet Message Format | 1994-04-30 | 4KB

Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA26406; Tue, 5 Apr 1994 20:24:57 -0400
Received: by usage.csd.unsw.OZ.AU id AA22673
  (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 6 Apr 1994 10:24:07 +1000
Received: by atlas (4.1/1.35)
    id AA11109; Wed, 6 Apr 94 10:37:09 EST
Message-Id: <9404060037.AA11109@atlas>
From: [e-mail]
Date: Wed, 6 Apr 1994 10:37:08 -0500
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: [e-mail],
        Multiple recipients of list <[e-mail]>
Subject: Re: Closing and reusing sockets

Thus expounded Bryan Boreham on Apr 5, 9:26am:
/--------------------
|> From: [e-mail]
|
|> To avoid WSAEADDRINUSE errors, you must make sure a socket is fully closed
|> before you can connect _from_the_same_port_number_ to the same remote
|> machine listening on the _same_remote_port_ - possibly by blocking in
|> a lingering close, or using linger to hard-close the connection when
|> you're done the first time.
|
|This is roughly what I said in the very first message in this thread --
|hard-closing
|the socket makes the problem go away.  I guess that waiting for the close to
|complete (probably not actually blocking, given that we're all nice cooperative
|Windows programmers) is gentler, but it would complicate the exit logic of the
|program rather a lot.
|
|This would all be a lot easier if we could rely on bind() giving EADDRINUSE
|so that the next port could be used instead, and leave the stack to
|get on with closing down the old one quietly.

True, but you still have to think about the case where your local machine
has closed the socket down OK, allowing you to BIND to the same
port number in the future, but the REMOTE end still has the same
port/address association valid, probably in TIMEWAIT state for two minutes.

In this case, your bind() will succeed, but the remote end may well refuse
the connection. WSAEADDRINUSE is a valid return from connect(),
as well as bind(). Also, if you set the socket option SO_REUSEADDR you will
be allowed to bind() to the same port number, on the assumption that you want
to connect to a different host/port from last time. If you try to connect()
to the same host/port as last time, you'll get back WSAEADDRINUSE from
connect().

Maybe if you describe what you are actually trying to do to the list,
instead of vague references to a private exchange, we might be able
to help you.


--
Paul Brooks              |[e-mail]       |Emerging Standard:
TurboSoft Pty Ltd        |[e-mail]|  one that has not yet
579 Harris St., Ultimo   |                         |  been superseded.
Sydney Australia 2007    |ph: [phone]       |
From [e-mail] Tue Apr  5 16:33:01 1994
Received: from EE.TAMU.EDU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA11603; Tue, 5 Apr 1994 22:31:34 -0400
Received: by ee.tamu.edu (5.61/1.34)
    id AA13007; Tue, 5 Apr 94 21:33:02 -0500
From: [e-mail] (Franklin S. Cheng)
Message-Id: <[e-mail]>
Subject: setoptsock()
To: [e-mail] (WINSOCK)
Date: Tue, 5 Apr 1994 21:33:01 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 765


Fellow hackers,

setoptsock() allows socket programmers to modify the socket
options, like the buffer size for sending and receiving.(using
level= SOL_SOCKET and optname= SO_RCVBUF and SO_SNDBUF)

My question is when the  _receiving_  buffer size is bigger than one UDP packet,
say 5 times. Will the incoming 5 packets be held in the buffer if
the app doesn't read it ? Or no matter how big the buffer size is,
it always holds just one UDP packet and discard the subsequence UDP
packets if the apps doesn't read it ? What about if the buffer size
is 5.3 times of the size of the incoming UDP packets , would the
6th one be stuffed into the remaining buffer size -- .3 of the UDP
packet ?

And how about the _sending_ buffer for this case ?

thanks,

Franklin.